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This release of the Mesa compiler introduces several changes of interest or importance to all 
Mesa programmers. A number of changes in the language have been made. Some of these 
will cause programs acceptable to previous compilers to be rejected unless those programs 
are modified. The reasons for making such changes are the following: 

To support new ways of describing configurations and binding them together. 

To add new facilities to the language. 

To prepare for certain language extensions that are now fairly well understood and 
for which preliminary designs exist. 

Language Changes Related to the Binder 

Overview 

The following overview might be helpful in understanding the changes related to the new 
binder. See the release summary for further references. 

The binder produces a configuration, which is a collection of module instances. Each 
module instance is represented by a global frame. Resolution of intermodular references is 
based upon copying descriptor and pointer values from well-defined interfaces into these 
global frames. More precisely, the binder produces configuration descriptions, which must 
be "relocated" by the loader to produce an actual configuration. 

There are two kinds of modules: definitions and program. The text of either kind implicitly 
defines a type. In the case of a program module X, this is a frame type, denoted by 
frame [A*]. Values of this type are created in the (frame) heap, either by loading or by the 
new operation. They cannot be embedded within larger aggregates but are referenced 
indirectly through pointers. In the case of a definitions module, the sequence of declarations 
implicitly defines an interface type. There is no explicit name for this type, but it is much 
like a record type with a field for each item in the interface. Instances of interface types, 
called interface records, can appear only as components of global frames, where they are 
anonymous. 

A program can export an interface, in which case a (partially) initialized interface record is 
created by the compiler. The initializing values represent procedures, signals, etc., declared 
within the program. (These values are "relocated" and made instance-specific each time the 
program is instantiated.) A program can also import an interface to gain access to externally 
defined procedures and the like. In this case, the interface record is left uninitialized by the 
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compiler. One job of the binder is to merge exported instances of each particular interface 
type and to assign the result to imported interfaces of the same type. The binder's 
Configuration Description Language is used to specify and control these assignments. 

A program also exports itself (as a pointer to its global frame) and can import instances of 
other programs (again, with access through frame pointers). In this case, the binder's job is 
to locate and assign the required (relocatable) frame pointers. 

Note 

The preceding discussion is conceptually accurate but should not be taken literally. 
The actual implementation of interfaces is somewhat more complicated and much 
more space-efficient than implied here. Exported interface records are part of each 
object file but have no existence during execution; furthermore, only those fields of 
imported records that are actually referenced occupy space in the global frame. 
Since the interface records do not exist as such during execution, they are sometimes 
called virtual interface records. 

Because the binder is a preprocessor, any code required to compute and assign the values of 
initialized variables cannot be run during binding. For uniformity, the language definition 
has been changed so that the effect of the new operator is limited to creating an instance of 
a global frame. The frame must be STARied to pass any required parameters and to 
initialize any nonconstant variables. The binder and loader perform the equivalent of a new 
but not a start. 

Defining Interfaces 

An interface type is defined by a definitions module. The form of such a module has not 
changed. It contains two sorts of declarations: 

(1) Constant definitions (including type definitions) 

(2) Interface element definitions (procedures, signals, etc). 

By convention, items of the first sort have identical values in all instances of the interface 
and can be referenced by specifying just the interface type. The fields of an interface 
record contain values of the second sort and correspond to the so-called "externals" found in 
previous versions of Mesa. 

One new type of interface element is available. The type constructor 

ProgramTC ::= program ParameterList ReturnsClause 

defines a type that can be used to declare a program variable. As part of an interface 
record, the value of a program variable is a pointer to a global frame of a like-named 
program. The declaration of a program variable specifies only input/output types; it does 
not provide access to the internal structure of a particular global frame. Uses of program 
variables are discussed below. 

Defining Program Modules 

A module gains access to another by including the (compiled) definitions file. As before, 
the directory construct makes the connection between the Mesa identifier denoting the 
module and the name of the object file. Note, however, that identifiers introduced in the 
directory now must match the module identifiers appearing in the original source. 
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Imported and exported items are "declared" in the heading of a program module using the 
following syntax (cf. Appendix D, Mesa Language Manual): 

ModuleHead ::= definitions ShareList 

| program ParameterList ReturnsClause 
ImportList ExportList ShareList 

ImportList ::= empty | imports ModuleList 

ExportList ::= empty j exports IdList 

ShareList ::= empty | shares IdList 

ModuleList ::= Moduleltem | ModuleList , Moduleltem 

Moduleltem ::= identifier | identifier : identifier 

The symbol data can be used in place of program, but there is no longer a 
distinction between program and data modules. Note also that the previous concept 
of implementing has been replaced by exports, and shares replaces sharing. 

Exporting Interfaces 

The value of each identifier in the exports list must be an interface type, i.e., a definitions 
module named in the directory. 

Procedures, signals, and errors are exported if they are public, have constant initialization 
and are named in some exported interface. In addition, the program itself (in the form of 
its global frame) is exported as part of an interface if its identifier appears there with an 
appropriate program type. (The global frame can also be exported independently of any 
interface; see below.) The compiler checks that the type of each exported item is assignment 
compatible with the type of the corresponding interface item. An item can be exported 
through more than one interface. 

It is permissible for a module to both import and export an interface; this is the normal case 
when a number of modules cooperate to provide a single interface. 

If a module exports Defs and defines a public identifier id, then Defs.id is bound 
directly (by the compiler) to the local definition, e.g., local procedure calls are used. 

Exporting an interface does not automatically provide access to its private components. 
Specifying shares (formerly sharing) allows such access to any module but does not 
automatically imply exports. 

Importing Interfaces 

After a module has been loaded, its imported interface records contain the linkages to other 
modules in the configuration. References to such linkages take the usual forms. The 
identifier of an interface item {Item) can be qualified by the name of the interface record 
(DefsJtem\_...~])\ alternatively, an interface record can be OPENed and the corresponding 
identifiers used without qualification (Item[...J). 

Arbitrary identifiers (preceding ":" in the imports list) can be associated with imported 
interface records so that several instances of the same interface type (perhaps bound 
differently) can be distinguished. If the identifier of an imported interface record is 
omitted, the name of the interface type is used by default, i.e., id is equivalent to id:id in an 
imports list (see the discussion of definitions from, however). The identifier following the 
colon must be defined in the directory. It can name an interface type, i.e., a definitions 
module. Alternatively, it can name a program module; this case is discussed later. 

It is important to distinguish between interface types (declared in the directory list) and 
interface records (declared in the imports list). Assume the following program skeleton: 
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directory Defsl: from "defsl", Defs2: from "defs2"; 
Prog: program imports Interface!: Defsl, Defsl = 

BEGIN ... END. 

Within the body of the program, Interfacel refers to an interface record; Defsl, to an 
interface type. If / is a type or a constant, both Interfacel. t and Defsl J are valid, and they 
have identical meanings. On the other hand, if proc is an interface item, Interfacel. proc 
names that item, but Defsl. proc is an error. The scope rules are arranged so that identifiers 
of the interface records introduced in the imports list are examined before those of the 
interface types introduced in the directory. Within the body of Prog, Defsl therefore refers 
to the interface record. Similar considerations apply to the use of the identifiers Interfacel, 
Defsl, and Defsl with open. Note that the distinction between the interface record and its 
type can be ignored unless the imported record is explicitly named. 

The definitions from construct does not mesh very well with imports and exports, but it is 
a well established feature of Mesa and the following convention has been adopted. Only an 
identifier introduced in the directory can appear in the list following definitions from. If 
an interface record of that type is imported but is not given an explicit name in the imports 
list, then the record is opened; otherwise, the type. Thus the default naming convention 
results in record instances being opened. In the example above, 

definitions from Defsl, Defsl', 

would open the type Defsl and the record Defsl. Again, confusion is possible only if the 
interface records are explicitly named. 

The external attribute provided by previous versions of Mesa has been withdrawn. 
Externally defined procedures and signals must now be components of imported interfaces 
or be passed into modules as explicit parameters. 

Importing and Exporting Program Modules 

Each program module exports itself, even if its module identifier is not mentioned in any 
interface. Any module can include a program module in its directory. A program module 
can import another by also mentioning that module in its own imports list. Since global 
frames cannot be embedded within other structures, the imported value in this case is a 
pointer to a global frame. The construct 

... imports ... frame: Prog ... 

has an effect similar to the declaration 

frame: pointer to frame I Prog"] = ... 

where the initializing value is computed and assigned by the binder. The same default 
naming convention applies; if frame were omitted, Prog would be used as the identifier of 
the pointer variable. 

Again, it is important to distinguish between the program constants declared in directory 
entries and the frame pointers supplied as imported values. Consider the following example: 

directory Progl: from "progl", Progl: from "prog2"; 

Prog: program imports frame I: Progl, Progl * 

BEGIN ... END. 
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Within the body of Prog, Progl names a program constant. The only legitimate uses for 
Progl are to define a frame type (pointer to frame[ Progl J) and to create new instances of 
that type (new Progl). The directory entry itself does not require the binder or loader to 
locate an existing instance of the program module. The appearance of Progl (and Progl) in 
the imports list does direct the binder to do this, however. Thus the value assigned to 
framel points to a global frame that is already part of the configuration, and framel can be 
used, e.g., to start that frame or to access its variables. By the default naming convention, 
the value of Progl within the main body is a pointer that can be used only to refer to a 
frame, not to a program constant, i.e., the construct pointer to frame[ Prog2\ would be 
illegal. 

Even if / denotes a type or constant, it is no longer possible to use Progl.t to name 
that value; framel. t remains acceptable, however. 

By importing a program directly, a module gains access to all the public variables in 
that particular program. Importing a program as an interface element does not give 
such access but also does not couple the importer to a particular exporter. This is 
discussed further below. 

Module Instantiation 

The new operator creates new instances of program modules. It can be invoked explicitly; it 
is also invoked implicitly by the binder/loader in the course of creating a configuration. In 
either case, new causes no code within the instantiated module to be executed. Instead, 
start is now used to pass any arguments and to start execution of the main body (including 
initialization code). 

The permissable operands of new are discussed below, new no longer permits an argument 
list, but the form 

new id [ ! ...] 

is still available for catching signals associated with instantiation. The value of a new 
operation is always a pointer to the newly created frame. 

Program modules now optionally return values. The allowed control disciplines depend 
somewhat upon whether a value is returned. Let framel and frame2 be pointers to frames 
of programs Progl and Progl respectively, and assume that Progl returns a value but Progl 
does not. 

The main body of Progl must contain a return statement. The first such return 
terminates execution of that body but does not cause deallocation of the global 
frame. Thus frame pointers remain valid, procedures declared within instances of 
Progl can be called and the like. The body of Progl cannot contain any stop 
statements. 

An expression with one of the forms 

start framel^...] 
start framef[... ! ...] 

is used to supply arguments to an instance of Progl and to initiate its execution. 
The value of the expression is the value returned by ProgL Execution of Progl 
cannot be restarted after return. 
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The main body of Prog2 cannot contain a return statement, but it can contain any 
number of stop statements. Execution of one of these suspends execution but causes 
no deallocation. 

A statement with one of the forms 

start frame2[...'] 
start frame2[... ! ...] 

is used to supply arguments to an instance of Prog2 and to initiate its execution. 
Execution of Prog2 can be restarted by one of the statement forms 

restart frame2 
restart frame2[ ! ...] 

Using alternating restarts and stops, two cooperating programs can execute as 
SiMULA-like coroutines. 

In all cases, the parameters of start are now type-checked, and there is no restriction on the 
number or size of such parameters. 

Any attempt to invoke a procedure prior to starting the enclosing program's initialization 
code causes a start trap. If the program requires no parameters and returns no results, the 
system will attempt to start the global frame and then retry the procedure call. Thus 
explicit starts (and the corresponding proliferation of frame pointers) are not required in 
many common situations. 

All imported interface variables are bound before the first start. On the other 
hand, a start trap occurs at most once for any given frame. Some care is therefore 
required when procedure calls during initialization can cycle through a set of frames; 
another procedure sharing the same global frame can be called before initialization 
is complete. 

In the following example, assume that a start trap occurs because of an extramodular 
call of ProcA2. If ProgramB has not been started either, ProcAl will be executed 
before some components of ProgramAs frame (such as w) are initialized. 

ProgramA: program imports DefsB exports DefsA = 

BEGIN 

v: T <r DefsB.procBl[...~\\ 

w: integer *• 0; 

ProcAl: public procedure [...] returns [...] = ... 
ProcA2: public procedure [...] = ... 

END. 



ProgramB: program imports DefsA exports DefsB 

BEGIN 

x: T <• DefsAProcAll...]; 

ProcBl: public procedure [...] returns [...] = 

END. 



Mesa 3.0 Compiler Update 7 

The implicit stop that was previously inserted between a module's initialization code and its 
main body (if non-void) has been removed. Such a stop must be specified explicitly. 

Program Variables and NEW 

Program types have been generalized. Their constructors have the following form: 

ProgramTC ::= program ParameterList ReturnsClause 

and they can be used anywhere type expressions are legal, e.g., to define named types or to 
declare program variables. Values of the latter are pointers to global frames. Such variables 
allow type-correct manipulation of frame pointers without requiring commitment to a 
particular frame type. Both pointers to frames and program variables can be STARTed. 

Imported interfaces can supply values for program variables as discussed above. In addition, 
the new operator creates such values dynamically. The domain of new has been extended to 
encompass the following two cases: 

Program Constants 

The identifier of the program module itself or of a directory entry denotes a 
program constant. When new is applied to such a value, the loader is invoked with a 
file name as an argument. The file name is taken from the directory or, in the case 
of the program's own identifier, constructed by the compiler. A global frame is 
allocated, the frame is connected to the code in the designated file, and imported 
interfaces within that frame are filled from the exported interfaces of the running 
configuration. This operation involves a directory search, etc., and is relatively 
expensive. 

In the current implementation, the designated file can contain only one 
program module. System procedures must be used to instantiate 
configurations consisting of several modules (see Mesa 3.0 System Update). 

Program Variables and Frame Pointers 

The value of a program or pointer variable is a pointer to an existing global frame. 
Application of new to such a value creates a new copy of that global frame. All 
interface records in the new frame are assigned copies of the corresponding records 
in the original frame, i.e., all bindings are inherited. Other variables within the 
frame are not copied. This operation is relatively inexpensive. 

In either case, the new frame is uninitialized, except for embedded interface records, until it 
is STARTed (perhaps by a start trap). 

Assume the declarations 

directory Prog: from "prog"; — assumed parameter less 

Module: program imports p: Prog = 

BEGIN 

progU prog2: program; 

frame: pointer to frame[ Prog~]\ 

end. 
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Then the valid assignments are summarized by the following list: 

frame «- p\ — copies a pointer 

frame «- new p\ — creates a copy of the imported frame 

frame *• new Progi — creates and binds a new instance 

progl <- prog2\ — copies a pointer 

progl «• new prog2\ — creates a copy of the frame 

prog/ <- new frame, — creates a copy of a frame with known type 

progl <- new /Vog; — creates and binds a new instance. 

Note that new yields a program type or a pointer type as required by context. 

The assignment frame <- progl is illegal. Although the following assignments are sensible, 
the current implementation does not support or allow them: 

progl ** frame; 
progl *• Prog . 

Program variables are useful for STARTing or replicating global frames when a client does 
not want to be coupled to the internal details of a particular implementation. 

Example: 

directory ProgDefs: from "progdefs"; 

Prog: program [/?; cardinal] exports ProgDefs - 

BEGIN 

v: public Thing 

Proc: public procedure = ...; 

END. 

ProgDefs: definitions = 

BEGIN 

Prog: program [cardinal]; 
Proc: procedure; 

END. 

A client that declares p: pointer to frame[/Vo£] (or, equivalently, imports p: Prog) 
receives a pointer to the global frame of the particular implementer Prog, That 
client is free to access, e.g., p.v; on the other hand, recompilation of all such clients is 
necessary when Prog changes (even trivially). A client that imports ProgDefs cannot 
mention ProgDefs. Prog.v, nor can Proc be referenced as ProgDefs. Prog.Proc. The 
appropriate value of Proc could be imported from the same interface, as suggested 
here. Alternatively, Prog could be changed so that the start of ProgDefs.Prog 
returned a value providing access to Proc. 

Importing ProgDefs instead of Prog decouples implementer and client. An internal 
change in the former does not require recompilation of the latter. Indeed, it is 
possible for several quite different and independent implementations all to export 
ProgDefs. 
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Other Language Changes 

Packed Arrays 

The attribute packed has been introduced to specify the packing of arrays. It can be used in 
the following type constructors: 

ArrayTC ::= packed array IndexType of TypeSpecification | ... 
ArrayDescriptorTC ::= descriptor for packed array of TypeSpecification | ... 

The idea is that, for a packed array, the compiler will choose the most compact 
representation that it is prepared to support. Currently, bytes and words are the only 
supported units of packing. Thus values of types that can be represented in 8 bits or less 
(e.g., boolean as well as character) are packed into bytes; all others are packed into words 
or integral multiples thereof. 

All the usual array operations, such as indexing, construction, assignment and comparison 
(for equality and inequality only), apply to packed arrays. Note the following: 

length applied to a packed array (or descriptor thereof) yields the number of 
elements, not the number of words. 

In the form descriptor [array], the packed attribute is inherited from array. In 
the form descriptor [base, n, type], the packed attribute is deduced from context. 
The second argument n always specifies the number of elements. 

Overlaid Variant Records 

In the declaration of a variant record type, the word overlaid can replace computed. 
Overlaid variants behave exactly as computed variants with the following extension: any 
field of a particular variant can be accessed without discrimination if the name of that field 
is unique with respect to both the common part and all other variants (including any 
overlaid variant subparts). 

Overlaid records can be used to breach the type system, as can variant records with 
computed tags in general. 

Example: 

R: type = record [ 
common: integer, 

variant: select overlaid Color from 
red => lb: boolean, /; [0..10)], 
blue => [/; integer, c: character], 
endcase]; 
v: R 

Then v.common, v,b, and v.c are all legal expressions. The first is always meaningful, 
but the second or third only makes sense if the value of v is a red R or a blue R 
respectively. The expression v.i is ambiguous and disallowed. 

If an overlaid variant record is OPENed, all uniquely named fields can be used without 
further qualification. Identifiers that do not name unique fields are visible but ambiguous; 
their use will be flagged, not ignored. On the other hand, opening an overlaid variant record 
using the with ... select construct or declaring a discriminated variant (e.g., a red R) works 
as usual. Independently of uniqueness of naming, fields of the selected variant are 
accessible, and fields of other variants are not. 
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Empty Intervals 

Empty intervals are now allowed in type declarations, notably in declarations of the index 
types of arrays. In the absence of genuine sequences, this change makes the simulation of 
them somewhat less painful. Note that the subrange, although empty, does establish the 
origin of the index set, e.g., [0..0) and [1..1) are not equivalent 

Example (see also the declaration of StringBody below): 

ThingSequence: type = machine dependent record [..., 
length: cardinal, 
value: array [0..0) of Thing}] -- the last field 

p: pointer TO ThingSequence <- Alloc[s\ZE[ThingSequence'] + /j*siZE[77i//ig]]; 
pt <~ [..., length: n y value: ]; p.value[Q <- ... 

The compiler allows ©p.value but flags any attempt to use a vacuous value itself, as 
in q. value <- p.value. Note that subscript bounds are being breached here, not the 
type system. 

Predeclared Identifiers 

Every Mesa program is compiled in an environment that in effect contains the following 
declarations: 

boolean: type = {FALSE, TRUE}; 
— make TRUE and FALSE pervasive 
true: boolean = TRUE; 
false: boolean = FALSE; 

string: type = pointer to StringBody; 
StringBody: type = machine dependent record [ 

length: cardinal, 

maxlength: —readonly— cardinal, 

text: packed array [0..0) of character]; 

UNWIND: error = code; 

string and boolean remain reserved words. 

boolean can now be used as the tag type of a variant record (but no new forms of select 
are provided). Note that false < true. 

The record type StringBody is declared in the way suggested above for simulating a 
sequence. As before, $[/] abbreviates s^Aext[i\ etc.; this abbreviation does not extend to 
other "faked" sequences. Subject to the caveats above, the declaration of StringBody 
provides a way of embedding string bodies within other data structures; pointers to such 
embedded records can be assigned to normal string variables without breaching the type 
system. 

Note that descriptors for the text portion of a string should be created using the 
form descriptor [@s.text, s.maxlength], not descriptor IsAexQ (which will yield 
an incorrect length). 

Identifier Clashes 
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It is now an error to declare the same identifier in both the input and output records of a 
procedure (program, signal, etc.) type. It is also an error to declare a local variable of a 
procedure (or program) by reusing an identifier of an input or output parameter of that 
procedure. 

Use of Type Expressions 

Arbitrary type expressions are now allowed as the arguments of size, first and last and as 
the final arguments of loophole and descriptor. Previously, these arguments were required 
to be type identifiers. 

Examples: 

LOOPHOLE [/>, POINTER TO R~] 

LOOPHOLE[/>ame, program [/?: integer]] 
size[array IndexSet of T} 

Compiler Changes 

An assortment of minor bugs have been fixed; as usual, the fixes are documented separately. 
The following changes are noteworthy. 

Variant Record Layout 

The internal layouts of variant records have been changed to eliminate uninitialized gaps 
following the common part and to solve some long-standing problems related to tag 
alignment in discriminated variants. As a consequence of the latter, some discriminated 
variants now occupy more storage. The amount of storage required for a variant record is 
governed by the following rules: 

If the minimum amount of storage required for every variant is a word or less, each 
variant is adjusted to occupy the same number of bits as the longest 

Otherwise, each variant is adjusted to occupy the minimum number of words. 

Both of these are changes. Some discriminated variants that fit into a single word now 
consume more bits. This can make a difference only when the discriminated variant is itself 
embedded within a record. 

Examples. 

Rl: type = record [ 

SELECT tag: * FROM 

red => lb: boolean], 
blue => [c: character], 
endcase]; 

R2: TYPE = RECORD [ 

select tag: * from 

null => NULL, 

yellow => lb: boolean], 

green => [/'; integer], 

endcase] 

The minimum storage required for fields of various types is given by the following 
table (changes are noted): 
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A7 9 

red Rl 9 (formerly 2) 

blue Rl 9 

R2 32 

null R2 16 (formerly 2) 

yellow R2 16 (formerly 3) 

green R2 32 

Since uninitialized gaps have been eliminated, comparison of two fully discriminated 
variants is now allowed. The compiler also permits comparison of undiscriminated values if 
there is an explicit tag and if all variants have the same length. 

Checking Machine Dependent Records 

The compiler now checks the declarations of machine dependent record types. The fields of 
such a record must specify a contiguous area of storage. Declarations in which gaps would 
appear between fields are flagged as errors. Packing is governed by the following rules: 

Fields minimally requiring a word or less cannot cross a word boundary. 

Fields requiring more than a word must begin on a word boundary and occupy an 
integral number of words. 

The first field begins on a word boundary. 

Records occupying more than a word must occupy an integral number of words. The 
lengths of variant machine dependent records must additionally conform to the rules stated 
in the previous section. 

Compiler Switches and Options 

Users of the compiler now have several options available. Switches that select the options 
are embedded (according to FTP's conventions) within the list of files to be compiled. The 
following switches are currently provided: 

Switch Option Controlled 

jsause Pausing after errors. 

warnings Generation of warning messages (see below). 

xref Generation of cross-reference data. 

In addition, 

command Converts the preceding string to a switch name. 

Within a list of files, the form option/c sets the corresponding option for successive files, 
and any unambiguous initial substring of the switch name can be used for option. The 
form file/o sets the options o for a single file only, and any sequence of unambiguous 
initial switch characters can be used for o. In either form, a "-" or "~" inverts the sense of 
an switch. Switches can appear in the command line or in responses to the compiler's 
prompt "Compile:". 
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The pause option conditionally causes the compiler to halt and request action from the user 
before proceeding. A pause occurs only if errors have been detected. This option is useful 
when input is taken from the command line; it gives the user a chance to acknowledge errors 
and to abort subsequent processing. If it is specified by a global switch (using pause/c), 
the conditional pause occurs only at the end of the entire sequence of compilations but is 
controlled by errors detected anywhere in that sequence. If this option is specified locally 
(using file/p), the compiler will pause if errors are detected in any file processed up to 
that point. 

The cross-reference information for source file Name. Mesa is written onto the file 
Name.XRJ for post- processing as described in separate documentation. 

Examples: 

Pause if errors are detected in any definitions file; generate a cross reference data 
and suppress warnings for prog2: 

defsl defs2 defs3/p progl prog2/x-w prog3 

Never pause: 

-pause/c . . . 

The default switch settings are equivalent to 

pause/c warnings/c -xref/c 

Warning Messages 

The compiler now optionally generates warning mesages when it detects legal but suspicious 
usage. Currently, the following situations are reported: 

A declared variable (but not a record field, input parameter, or return value) that is 
not public and is never referenced within the module containing its declaration. (See 
also Identifier Clashes above). 

Comparisons such as c < 0, when c is a cardinal. 

An initializing declaration that assigns the same non-NiL pointer or descriptor value 
to two or more variables (in particular, string variables). 

Interfaces that are imported but not used. 

Declared identifiers that are not public but appear in some exported interface. 

Warning messages appear in the error log but do not abort compilation. Generation of these 
messages is controlled by the w switch. The default is to print warnings; -w inhibits this. 

Source/Object Mapping 

The resolution of the tables recording source-object correspondence has been increased to 
the level of statement boundaries. Previously, only the intersections of statement and source 
line boundaries were recorded. This change allows more precise placement of breakpoints. 

Entry Point Limit 
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Certain internal formats have been changed in a way that limits the number of entry items 
within a single program module to 128. This number is the maximum of the number of 
procedure (or program) bodies and the number of signal (or error) codes. This limit is also 
built into the DO and Dorado hardware. 

In addition, the number of interface items declared within a single definitions module 
cannot exceed 128. This number is the sum of the number of procedure, program, signal 
and error declarations. 

Module Compatibility 

Module Formats 

The format of object modules has been changed to contain the information required by the 
new binder. The output of the compiler is a degenerate configuration description which can 
be processed by either the binder or the loader. This change requires the recompilation of 
all existing Mesa programs. To emphasize this change, the extension used for object file 
names has been changed from XM to BCD (binary configuration description). 

Interface Versions 

All type checking has been moved into the compiler; the binder and loader simply match 
interfaces according to interface (file) name and version stamp. It is therefore essential that 
consistency of definitions modules be maintained within configurations, even when such 
modules contain no type declarations. 



Distribution 

MesaUsers 
MesaGroup 



